IETF Logo Mail Archive

Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...)

Shane Amante <shane@castlepoint.net> Mon, 15 August 2011 17:01 UTC

Return-Path: <shane@castlepoint.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036F821F8C86 for <v6ops@ietfa.amsl.com>; Mon, 15 Aug 2011 10:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIERZPtJW6d9 for <v6ops@ietfa.amsl.com>; Mon, 15 Aug 2011 10:01:27 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5698321F8C85 for <v6ops@ietf.org>; Mon, 15 Aug 2011 10:01:27 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 5EF0626806D; Mon, 15 Aug 2011 11:02:13 -0600 (MDT)
Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 15 Aug 2011 11:02:13 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=54961; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com>
Date: Mon, 15 Aug 2011 11:02:11 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <28E09383-C957-485D-8B15-12EE742D9A2F@castlepoint.net>
References: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com>
To: nalini.elkins@insidethestack.com
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 17:01:28 -0000

Nalini,

On Aug 15, 2011, at 8:57 AM, nalini.elkins@insidethestack.com wrote:
>> Have you taken a look at flow-spec for IPv4:
>> http://tools.ietf.org/html/rfc5575
>> ... and, flow-spec for IPv6:
>> http://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-00
>> (Both the RFC and I-D are within the IDR WG).
>> 
>> In summary, using flow-spec one can define an ACL that then
>> get distributed across all routers within an ASN, via BGP,
>> that can then be used to count matching packets, log packet
>> header information, etc.  It's up to the operator to
>> decide what ACL to be applied and what 'action' (logging,
>> counting, etc.) to be taken for packets that match a given
>> 'rule'.  
>> 
>> From where I'm sitting, this seems like it might already
>> solve the problem you're having, without having to invent a
>> wholly new IPv6 Destination Header Option.  So, I would
>> like to know if you have taken a look at flow-spec and, if
>> so, why it was ruled out?
> 
> Certainly an interesting set of RFCs but a few questions I would have:
> 
> 1.  What if BGP is not being used?

Turn it on?

There are a plethora of books, training materials/sessions, know-how, best practices, etc. documented and presented over the years, including those given at various *NOG's ... if folks want/need pointers on where to start, I (and others) would be happy to provide them.


> 2.  What about matching packets at non-router devices (that is, hosts)

Use tcpdump and/or wireshark?


> 3.  I believe what we need in diagnostics is the entire packet not just a logging that such a packet existed.  For example, the problem we are looking for may be in the body of the protocol data.  Ex. a problem with FTP.  So, we would need the entire packet as captured by a packet analyzer rather than a log that says 'a packet from dest x to source y was sent'.  I do not imagine that the log is going to keep the entire packet.  Am I missing something?

Take a look at RFC 5575.  It supports the idea of redirecting packets that match a flow-spec 'rule' to an IPVPN VRF.  I believe the reason this was done was to ensure (a copy of) the packet would be sent to a centralized collector(s) that could perform detailed packet analysis on the contents/payload of recv'd packets that are being sampled.

In short, I think this is a solved problem and there isn't a need for a IPv6 Diagnostic Header Destination Option.

-shane

v2.23.0 | Report a Bug | By Email